In a normal Terminal Services session, a user's applications reside on a terminal server rather than on the user's client terminal. When connected, the desktop of the remote machine will be displayed, and the user will interact with the remote terminal server. In this case, the user is basically using the server's operating system as his or her own. Accordingly, in this case the server's operating system knows about applications that are installed on the server. When a user runs a normal Terminal Services session, the user simply establishes a connection to the server using client software that communicates with the user using an appropriate protocol such as the Remote Desktop Protocol (RDP), for example.
RDP is a multi-channel protocol that allows a user to connect to a computer running Microsoft Terminal Services, which is a component of Microsoft Windows operating systems that allow a user to access applications or data stored on a remote computer over a network connection. Remote Desktop Protocol (RDP) files contain configuration information for the Terminal Services client on how to connect to a Terminal Server, and if applicable, which remote application or program to launch once connected.
In some cases however, running remote applications or programs works differently—while the remote applications are running on the server's operating system, the users do not use the server's operating system as their own operating system. Rather, the user clients are running their own individual copies of Windows, which contain links or menu icons to the remote programs. To implement this embodiment, Terminal Services Client software is installed on the client system, and the user client can go through TS Web Access. Alternatively, the user client can install an .msi file or can simply click on an RDP file that has been installed on their system. The user also must either have a link to the remote program, or can visit a TS Web Access site to access the remote program. This link will appear as either a shortcut on the user client's desktop, as an application on the user's Start menu, or as a link accessed by visiting a configured TS Web Access website. In the case of the RDP protocol, the file that acts as a link to the remote program uses the .RDP extension. To make the remote program available to users, the user clicks on the corresponding link. An MSI file can be created that allows file extensions to be taken over (e.g., double clicking on a .doc file opens up the associated remote program), the ability to add icons, add start menu entries, etc.
The use of an MSI file provides many advantages over manual installation of the RDP file. For example, with MSI files if a critical file for an installed application is deleted or damaged, the application can simply repair itself, which is a so-called self-healing benefit. The application used to create the MSI file needs to be able to “key” critical files, and then grabs the needed file from the original source, allowing the application to just keep running. Additionally, the creation of an MSI installation package allows for the distribution of the package using a group policy or other software deployment utility.
MSI files are structured as OLE Structured Storage Files, and are essentially relational databases packaged in installation packages that include installation information and the software files themselves, and are used by the Windows Installer engine for the installation, maintenance and removal of software on Microsoft Windows systems. As previously noted, MSI files essentially act as an installer for the RDP files. Without the MSI file (i.e., the database of all the files, settings, and configuration information for the associated application), Windows Installer cannot update configurations, install optional features, or apply software updates. Office cannot be installed, repaired, or updated if the MSI file is not found.
Using the Terminal Services Remote Programs command, MSI files may be created for the RDP files that have been configured to run remotely. This MSI installation package may then be used to deploy the remote program onto network clients. This allows administrators to maintain centralized control of applications, while still allowing users to retain their own individual desktops.
The MSI format integrates with a running Windows service, helping administrators deploy applications via Active Directory and Group Policy. Active Directory (AD) gives administrators a way to publish MSI files for the users in their organization. The use of AD gives the administrators a way to restrict groups of users in accessing certain groups of RDP files as well. Additionally, this capability helps deploy packages without requiring users to hold administrative credentials on the clients. Since users don't need administrative rights to install applications when the MSI format is used, security can be more readily maintained.
Unfortunately, once an RDP file is placed inside an MSI file there is no way to update that file without creating a new MSI file in which the updated RDP file is placed. Many times the person creating the RDP files for the Terminal Server will have administrator privileges for only the Terminal Server and not domain administrator privileges to update the MSI files that are being published through AD. This leads to the Terminal Server Administrator updating the RDP files, but the RDP files in the MSI files become outdated and in some cases unusable until the MSI files are re-created and re-published through AD.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follows. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to only those implementations that may solve any or all of the disadvantages or problems presented above.